Certain integrated circuits such as programmable logic devices (PLDs) require configuration by the user before normal operation. Various programming systems exist that enable a user to shift in configuration data into the PLD to effect a desired logical function. There are corresponding types of elements or components that are configured by the resulting stored configuration data within the PLD. The primary component being configured may be referred to as the programmable fabric—in the case of a field programmable gate array (FPGA), the programmable fabric includes a plurality of lookup-table-based logic blocks as well as an associated routing structure. The configuration data for the programmable fabric is typically stored in a volatile FPGA memory (SRAM) and is shifted into the device through a dedicated data shift register (DSR).
The configuration process typically starts with the user translating the desired logical function into a hardware description language (HDL) on the programming system, which is typically a PC configured with the appropriate programming software. The programming PC, through its associated software, translates the user's HDL into a netlist. This netlist is then mapped by the programming PC to the resources corresponding to the particular type of PLD being configured such as a particular field programmable gate array (FPGA). The programming system can then perform a route-and-place routine in which the logic elements from the user's design are assigned to corresponding resources within the FPGA being programmed. The resulting mapping is fine-tuned and debugged during a simulation stage. Once the design is deemed satisfactory, a corresponding bitstream is generated for downloading into the FPGA
A user interacts with the PLD programming software through a main graphical user interface (GUI). The design software process also uses a number of graphical user interface (GUI) tools that interface with the main GUI. For example, a floorplan view tool allows the designer to view design placement and edit placement constraints. A package view tool provides a graphical assignment of signals to I/O pins. A physical view tool illustrates the physical routing of paths to provide a more detailed understanding of timing issues. Other common tools include a hardware debugger and a power calculator.
A common feature of a tool graphical user interface is the ability to cross probe to other tool graphical user interfaces. For example, a user may select a feature such as an input/output pin in a first tool GUI (denoted as a source tool GUI) and observe this same feature selected in one or more of the remaining tool GUIs (denoted as the target tool GUI(s)). A conventional approach to enable cross probing is the use of dedicated function calls between the source tool GUI and the one or more target tool GUIs. But such a methodology requires a specific handshaking protocol between the tools that is inefficient. Moreover, the handshaking becomes unmanageable as the number of target tool GUIs is increased from one target tool GUI to many target tool GUIs.
Accordingly, there is a need in the art for improved software architectures that simplify the cross probing process.